Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Change logic for generating/loading stack to avoid mismatching key errors #2282

Closed

Conversation

craddm
Copy link
Contributor

@craddm craddm commented Nov 7, 2024

✅ Checklist

  • You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
  • You are targeting the appropriate branch. If you're not certain which one this is, it should be develop.
  • Your branch is up-to-date with the target branch (it probably was when you started, but it may have changed since then).

🚦 Depends on

⤴️ Summary

When a new stack is created (e.g. during the first run of dsh sre deploy x), a new encrypted key is generated when trying to load the stack and stored in the local workspace used for this run of the function. This doesn't match the project encrypted key.

When an existing stack is selected (such as on a second run of dsh sre deploy x), the project key is used correctly.

The create_or_select_stack function doesn't tell you whether a stack was created or selected. This PR splits select_stack and create_stack separately, catching errors from the stack not existing or already existing respectively. If the stack is being created, then manually overwrite the newly generated key with the existing project key.

An alternative would be to keep the existing create_or_select_stack function and always overwrite the generated key with the project key

Either way, the separate step of checking if the keys match is no longer required, as the keys will always match.

🌂 Related issues

Closes #2249

🔬 Tests

Tested locally

Copy link

github-actions bot commented Nov 7, 2024

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  data_safe_haven/infrastructure
  project_manager.py 154-157
Project Total  

This report was generated by python-coverage-comment-action

@craddm
Copy link
Contributor Author

craddm commented Nov 12, 2024

Closing this as issue appears to have been fixed by updating Pulumi CLI to 1.138.0

@craddm craddm closed this Nov 12, 2024
@craddm craddm deleted the stack-encrypted-key branch December 3, 2024 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stack encrypted key does not match project encrypted key - intermittent deployment error
1 participant